Method and apparatus for dynamic configuration of multiprocessor system

ABSTRACT

A multiprocessor system used in a car, home, or office environment includes multiple processors that run different real-time applications. A dynamic configuration system runs on the multiple processors and includes a device manager, configuration manager, and data manager. The device manager automatically detects and adds new devices to the multiprocessor system, and the configuration manager automatically reconfigures which processors run the real-time applications. The data manager identifies the type of data generated by the new devices and identifies which devices in the multiprocessor system are able to process the data. 
     A communication system for a mobile vehicle, home, or office environment includes multiple processors. The multiple processors each run an Open Communication system that controls how data is transferred between processors based on data content as opposed to the links that connect the processors together. The open communication system enables data or messages to be effectively transferred and processed for real-time applications or other server based applications that may be running on the multiple processors in a secure environment regardless of processors, locations, or data links.

RELATED FILINGS

This application is a continuation of U.S. patent application Ser. No.11/462,958 filed Aug. 7, 2006 now U.S. Pat. No. 7,778,739, that is acontinuation of U.S. patent application Ser. No. 09/841,915, filed Apr.24, 2001, now U.S. Pat. No. 7,146,260 issued on Dec. 5, 2006, thedisclosures of which are incorporated herein by reference in theirentirety.

REFERENCES CITED U.S. Patent Documents

-   U.S. Pat. No. 4,829,434 May 1989; Karmel et al.-   U.S. Pat. No. 5,581,462 December 1996; Rogers-   U.S. Pat. No. 5,786,998 July 1998; Neeson et al.-   U.S. Pat. No. 6,161,071 December 2000; Shuman et al.-   U.S. Pat. No. 6,181,994 January 2001; Colson et al.-   U.S. Pat. No. 6,182,006 January 2001; Meek-   U.S. Pat. No. 6,243,450 June 2001; Jansen et al.-   U.S. Pat. No. 6,505,100 January 2003; Stuempfle et al.-   U.S. Pat. No. 6,622,083 September 2003; Knockeart et al.

Foreign Patent Documents WO96/24229 August, 1996 WO WO99/08436 February,1999 WO WO99/57662 November, 1999 WO WO99/65183 December, 1999 WOWO01/30061 April, 2001 WO WO01/58110 August, 2001 WO Other References

Product description of Raytheon RT Secure, “Embedded Hard Real-TimeSecure Operating System”, Copyright 2000, pp. 1-2. cited by other.

Product description of Raytheon RT Secure, Copyright 2001, pp. 1-2.cited by other.

Product description of Raytheon RT Secure, “Development Environment”,Copyright 2001, pp. 1-2. cited by other.

Product description of Raytheon Electronic Systems (ES), Copyright 2002,pp. 1-2. cited by other.

H. Chung, L. Ojeda, and J. Borenstein, “Sensor Fusion for Mobile RobotDead-reckoning with a Precision-calibrated Fiber Optic Gyroscope”, 2001IEEE International Conference on Robotics and Automation, Seoul, Korea,May 21-26, pp. 1-6. cited by other. A. Das, R. Fierro, V. Kumar, J.Ostrowski, J. Spletzer, and C. Taylor, “A Framework for Vision BasedFormation Control”, IEEE Transactions on Robotics and Automation, vol.XX, No. Y, 2001, pp. 1-13. cited by other.

J. Takezaki, N. Ueki, T. Minowa, H. Kondoh, “Support System for SafeDriving—A Step Toward ITS Autonomous Driving—”, Hitachi Review, vol. 49,No. 3, 2000, pp. 1-8. cited by other.

S. G. Goodridge, “Multimedia Sensor Fusion for Intelligent CameraControl and Human-Computer Interaction”, Dissertation submitted to theGraduate Faculty of North Carolina State University in partialfulfillment of the requirements for the degree of Doctor of Philosophyin Electrical Engineering, Raleigh, N.C., 1997, pp. 1-5. cited by other.M. Chantler, G. Russel, and R. Dunbar, “Probabilistic Sensor Fusion forReliable Workspace Sensing”, pp. 1-14. cited by other.

ISIS Project: Sensor Fusion, Linkoping University Division of AutomaticControl and Communication Systems in cooperation with SAAB (Dynamics andAircraft), 18 pages. cited by other.

Hitachi Automated Highway System (AHS), Automotive Products, Hitachi,Ltd., Copyright 1994-2002, 8 pages. cited by other.

Vehicle Dynamics Lab, University of California, Berkeley, funded by BMW,current members: D. Caveney and B. Feldman, “Adaptive Cruise Control”,17 pages. cited by other.

Counterair: The Cutting Edge, Ch. 2 “The Evolutionary Trajectory TheFighter Pilot—Here to Stay?” AF2025 v3c8-2, December 1996, pp. 1-7.cited by other.

Counterair: The Cutting Edge, Ch. 4 “The Virtual Trajectory AirSuperiority without an “Air” Force?” AF2025 v3c8-4, December 1996, pp.1-12. cited by other.

TNO FEL Annual Review 1998: Quality works, 16 pages. cited by other.

Boeing News Release, “Boeing Demonstrates JSF Avionics Multi-SensorFusion”, Seattle, Wash., May 9, 2000, pp. 1-2. cited by other.

Boeing Statement, “Chairman and CEO Phil Condit on the JSF Decision”,Washington, D.C., Oct. 26, 2001, pp. 1-2. cited by other.

Ada 95 Transition Support—Lessons Learned, Sections 3, 4, and 5, CACI,Inc.—Federal, Nov. 15, 1996, 14 pages. cited by other.

Joint Strike Fighter Terrain Databaste, ets-news.com “SimulatorSolutions” 2002, 3 pages. cited by other.

MSRC Redacted Proposal, 3.0 Architecture Development, pp. 1-43. cited byother.

Powerpoint Presentation by Robert Allen—Boeing Phantom Works entitled“Real-Time Embedded Avionics System Security and COTS OperatingSystems”, Open Group Real-Time Forum, Jul. 18, 2001, 16 pages. cited byother.

Green Hills Software, Inc., “The AdaMULTI 2000 Integrated DevelopmentEnvironment”, Copyright 2002, 7 pages. cited by other.

Luttge, Karsten: “E-Charging API: Outsource Charging to a PaymentService Provider”; IEEE; 2001 (pp. 216-222). cited by other.

BACKGROUND

Cars include many different electromechanical and electronicapplications. Examples include braking systems, electronic securitysystems, radios, Compact Disc (CD) players, internal and externallighting systems, temperature control systems, locking systems, seatadjustment systems, speed control systems, mirror adjustment systems,directional indicators, etc. Generally the processors that control thesedifferent car systems do not talk to each other. For example, the carradio does not communicate with the car heating system or the carbraking system. This means that each one of these car systems operateindependently and do not talk to the other car systems. For example,separate processors and separate user interfaces are required for thecar temperature control system and for the car audio system. Many ofthese different car processors may be underutilized since they are onlyused intermittently.

Even when multiple processors in the car do talk to each other, they areusually so tightly coupled together that it is impossible to change anyone of these processors without disrupting all of the systems that arelinked together. For example, some cars may have a dashboard interfacethat controls both internal car temperature and a car radio. The carradio cannot be replaced with a different model and still work with thedashboard interface and the car temperature controller.

Integration of new systems into a car is also limited. Car systems aredesigned and selected well before the car is ever built. A custom wiringharness is then designed to connect only those car systems selected forthe car. A car owner cannot incorporate new systems into the existingcar. For example, a car may not originally come with a navigationsystem. An after market navigation system from another manufacturercannot be integrated into the existing car.

Because after market devices can not be integrated into car control andinterface systems, it is often difficult for the driver to try andoperate these after market devices. For example, the car driver has tooperate the after market navigation system from a completely newinterface, such as the keyboard and screen of a laptop computer. Thedriver then has to operate the laptop computer not from the frontdashboard of the car, but from the passenger seat of the car. This makesmany after market devices both difficult and dangerous to operate whiledriving.

Cars include many different electromechanical and electronic systems.Examples include braking systems, electronic security systems, radios,Compact Disc (CD) players, internal and external lighting systems,temperature control systems, locking systems, seat adjustment systems,speed control systems, mirror adjustment systems, directionalindicators, etc. Generally the processors that control these differentcar systems do not talk to each other. For example, the car radio doesnot communicate with the car heating system or the car braking system.This means that each one of these car systems has to provide a separatestandalone operating system. For example, separate processors andseparate user interfaces are required for the car temperature controlsystem and for the car audio system. Many of these different carprocessors may be underutilized since they are only used intermittently.

Even when some processors in the car do talk to each other, they areusually so tightly coupled together that it is impossible to change anyone of these processors without disrupting all of the systems that arelinked together. For example, some cars may have an interface on thedashboard that controls both internal car temperature and a car radio.The car radio cannot be replaced with a different model and still workwith the dashboard interface and the car temperature controller.

Integration of new systems into a car is also limited. Car systems aredesigned and selected well before the car is ever built. A custom wiringharness is then designed to connect all the car systems selected for thecar. A car owner can not later incorporate new systems into the existingcar. For example, a car may not originally come with a car navigationsystem. An after market navigation system from another manufacturercannot be integrated into the car.

Because after market devices can not be integrated into car control andinterface systems, it is often difficult for the driver to try andoperate these after market devices. For example, the car driver has tooperate the after market navigation system from a completely newinterface, such as the keyboard and screen of a laptop computer. Thedriver then has to operate the laptop computer, not from the frontdashboard of the car, but from the passenger seat of the car. This makesmany after market devices both difficult and dangerous to operate whiledriving.

The present invention addresses this and other problems associated withthe prior art.

SUMMARY OF THE INVENTION

A multiprocessor system used in a car, home, or office environmentincludes multiple processors that run different real-time applications.A dynamic configuration system runs on the multiple processors andincludes a device manager, configuration manager, and data manager. Thedevice manager automatically detects and adds new devices to themultiprocessor system, and the configuration manager automaticallyreconfigures which processors run the real-time applications. The datamanager identifies the type of data generated by the new devices andidentifies which devices in the multiprocessor system are able toprocess the data.

A communication system for a mobile vehicle, home, or office environmentincludes multiple processors. The multiple processors each run an OpenCommunication system that controls how data is transferred betweenprocessors based on data content as opposed to the links that connectthe processors together. The open communication system enables data ormessages to be effectively transferred and processed for real-timeapplications or other server based applications that may be running onthe multiple processors in a secure environment regardless ofprocessors, locations, or data links.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a car that has multiple processors that each runa Dynamic Configuration (DC) system.

FIG. 2 is a detailed diagram of the dynamic configuration system shownin FIG. 1.

FIGS. 3 and 4 are diagrams showing an example of how the DC systemoperates.

FIGS. 5 and 6 are diagrams showing how a device manager in the DC systemoperates.

FIGS. 7-10 are diagrams showing how a reconfiguration manager in the DCsystem operates.

FIGS. 11 and 12 are diagrams showing how a data manager in the DC systemoperates.

FIG. 13 is a diagram showing different multiprocessor systems that canuse the DC DC system.

FIG. 14 is a diagram of a car that have multiple processors that eachrun an open communication system.

FIG. 15 is a block diagram of the open communication system shown inFIG. 14.

FIG. 16 is a flow diagram showing how a priority manager processesoutgoing data in the open communication system.

FIG. 17 is a flow diagram showing how the priority manager receives datain the open communication system.

FIG. 18 is a flow diagram showing how a logging manager processes datain the open communication system.

FIG. 19 is a flow diagram showing how a security manager processes datain the open communication system.

FIG. 20 is a diagram showing one example of how the open communicationsystem is used by different processors.

FIG. 21 is a diagram of a tracking report that is generated by the opencommunication system.

FIG. 22 is a flow diagram showing how different image data is processedand transmitted using the open communication system.

FIG. 23 is a flow diagram showing how the transmitted image data in FIG.22 is received and processed using the open communication system.

FIG. 24 is a block diagram showing another example of how the openconnection system operates.

DETAILED DESCRIPTION

FIG. 1 shows a car 6012 that includes a car multiprocessor system 6008having multiple processors 6014, 6016, 6018 and 6020. An engine monitorprocessor 6014 monitors data from different sensors 6022 and 6024 in thecar engine. The sensors 6022 and 6024 can be any sensing device such assensors that monitor water temperature, oil temperature, fuelconsumption, car speed, etc. A brake control processor 6020 monitors andcontrols an Automatic Braking System (ABS) 6028. A display processor6016 is used to control and monitor a graphical user interface 6026. Asecurity processor 6018 monitors and controls latches and sensors 6030and 6032 that are used in a car security system.

The processors 6014, 6016, 6018 and 6020 all include software that run aDynamic Configuration (DC) system 6010 that enables new processors ordevices to be automatically added and removed from the carmultiprocessor system 6008. The DC system 6010 also automaticallyreconfigures the applications running on different processors accordingto application failures and other system processing requirements.

For example, the processor 6020 may currently be running a high prioritybrake control application. If the processor 6020 fails, the DC system6010 can automatically download the braking application to anotherprocessor in car 6012. The DC system 6010 automatically identifiesanother processor with capacity to run the braking control applicationcurrently running in processor 6020. The DC system 6010 thenautomatically downloads a copy of the braking control application to theidentified processor. If there is no extra reserve processing resourcesavailable, the DC system 6010 may replace a non-critical applicationrunning on another processor. For example, the DC system 6010 may causethe display processor 6016 to terminate a current non-criticalapplication and then download the brake control application along withany stored critical data.

The DC system 6010 also automatically incorporates new processors orapplications into the multiprocessor system 6008. For example, a laptopcomputer 6038 can communicate with the engine monitor processor 6034through a hardwired link 6034 or communicate to the display processor6016 through a wireless link 6036. The DC system 6010 automaticallyintegrates the laptop computer 6038, or any other processor or device,into the multiprocessor system 6008. After integrated into themultiprocessor system 6008, not only can the laptop computer 6038transfer data with other processors, but the laptop computer may alsorun car applications normally run by other processors in car 6012.

The DC system 6010 allows the car driver to manage how differentapplications are processed in the car 6012. As described above, a caroperator may have to run an aftermarket navigation system through a GPStransceiver attached to the laptop computer 6038. The car driver has toplace the laptop computer 6038 in the passenger's seat and then operatethe laptop computer 6038 while driving.

The DC system 6010 in the display computer 6016 can automatically detectthe navigation application running on the laptop computer 6038. Thedisplay computer 6016 notifies the car operator through the userinterface 6026 that the navigation application has been detected. Thecar operator can then control the navigation application through theuser interface 6026. Since the user interface 6026 is located in thedashboard of car 6012, the car operator no longer has to take his eyesoff the road while operating the navigation application.

The description below gives only a few examples of the differentprocessors, devices and applications that can be implemented using theDC system 6010. Any single or multiprocessor system located eitherinside or outside of car 6012 can communicate and exchange data usingthe OC system 6010. It should also be understood that the DC system 6010can be used in any real-time environment such as between processors indifferent home or office appliances and different home and officecomputers.

FIG. 2 is a block diagram showing in more detail the Dynamic Control(DC) system 6010 located in a processor 6040 that makes up part of themultiprocessor system 6008 in car 6012 (FIG. 1). The DC system 6010includes a device manager 6046 that establishes communications with newdevices that are to be incorporated into the multiprocessor system 6008.A configuration manager 6044 in the processor 6040 dynamically movesapplications between different processors according to user inputs andother monitored conditions in the multiprocessor system 6008. A datamanager 6042 identifies a type of data input or output by a newprocessor and identifies other processors or devices in themultiprocessor system that can output data from the new device or inputdata to the new device.

In one example, sensors 6052 feed sensor data to processor 6040. Thesensor data may include engine-monitoring data such as speed, oiltemperature, water temperature, temperature inside the car cab, dooropen/shut conditions, etc. The sensors 6052 are coupled to processor6040 through a link 6054, such as a proprietary bus. A Compact Disc (CD)player 6050 is coupled to the processor 6040 through another link 6048,such as a Universal Serial Bus (USB). Graphical User Interface (GUI)6056 displays the data associated with sensors 6052 and CD player 6050.The GUI 6056 displays the outputs from sensors 6052 using an icon 6060to identify temperature data and an icon 6062 to identify car speed. Theprocessor displays the CD player 6050 as icon 6062.

FIGS. 3 and 4 show an example of how two new applications aredynamically added to the multiprocessor system 6008 in car 6012 (FIG.1). In FIG. 2, the DC system 6010 in processor 6040 previously detecteda CD player 6050 and some sensors 6056. The CD player 6050 was displayedon GUI 6056 as icon 6058 and the temperature and speed data from sensors6056 were displayed on GUI 6056 as icons 6060 and 6062, respectfully.

The processor 6040 is located in car 6012 (FIG. 1). A passenger maybring a Digital Video Disc (DVD) player 6086 into the car 6012. The DVD6086 sends out a wireless or wired signal 60088 to the processor 6040.For example, the DVD 6086 may send out signals using a IEEE 802.11wireless protocol. The processor 6040 includes an IEEE 802.11 interfacethat reads the signals 60088 from DVD player 6086. If the 802.11protocol is identified as one of the protocols used by processor 6040,the DC system 6010 incorporates the DVD player 6086 into a processorarray 6057 that lists different recognized applications.

The DC system 6010 then automatically displays the newly detected DVDplayer 6086 on GUI 6056 as icon 6096. If capable, the car operator byselecting the icon 6096 can then display a video stream output from theDVD player 6086 over GUI 6056. The DVD player 6086 can now be controlledfrom the GUI 6056 on the car dashboard. This prevents the car driverfrom having to divert his eyes from the road while trying to operate theportable DVD player 6086 from another location in the car, such as fromthe passenger seat.

Other processors or devices can also be incorporated into themultiprocessor system 6008 in car 6012. In another example, the car 6012drives up to a drive-in restaurant 6090. The drive-in 6090 includes atransmitter 6092 that sends out a wireless Blue tooth signal 6094. Theprocessor 6040 includes a Blue tooth transceiver that allowscommunication with transmitter 6092. The DC system 6010 recognizes thesignals 6094 from transmitter 6092 and then incorporates the drive-in6090 into the multiprocessor system 6008 (FIG. 1). The DC system 6010then displays the drive-in 6090 as icon 6098 in GUI 6056.

Referring to FIG. 4, when the car operator selects the icon 6098, a menu60102 for the driver-in 6090 is displayed on the GUI 6056. The caroperator can then select any of the items displayed on the electronicmenu 60102. The selections made by the car operator are sent back to thetransceiver 6092 (FIG. 3). The amount of the order is calculated andsent back to the processor 6040 and displayed on menu 60102. Othermessages, such as a direction for the car operator to move to the nextwindow and pickup the order can also be displayed on the GUI 6056. Atthe same time, the drive-in transceiver 6092 (FIG. 3) may send audiosignals that are received by the processor 6040 and played out overspeakers in car 6012.

FIG. 5 shows in more detail the operation of the device manager 6046previously shown in FIG. 2. Multiple processors A, B, C and D allinclude device managers 6046. The device managers 6046 can each identifyother devices in the multiprocessor system that it communicates with.For example, processors A, B, C and D communicate to each other over oneor more communication links including a Ethernet link 6064, a wireless802.11 link 6068, or a blue tooth link 6070.

Processor A includes a memory 6065 that stores the other recognizedprocessors B, C and D. The data managers 6046 also identify anyapplications that may be running on the identified processors. Forexample, memory 6065 for processor A identifies an application #2running on processor B, no applications running on processor C, and anapplication #4 running on processor D.

FIGS. 5 and 6 show how a new device is added to the multiprocessorsystem 6008. Each of the existing processors A, B, C, and D afterpower-up are configured to identify a set or subset of the processors inthe multiprocessor system 6008. A new device 6072 is brought into themultiprocessor system 6008 either via a hardwired link or a wirelesslink. For example, the device E may send out signals over any one ormore of a 802.11 wireless link 6067, Blue tooth wireless link 71 or sendout signals over a hardwired Ethernet link 6069. Depending on whatcommunication protocol is used to send signals, one or more of theprocessors A, B, C or D using a similar communication protocol detectthe processor E in block 6074 (FIG. 6). All of the processors may beconnected to the same fiber optic or packet switched network that isthen used to communicate the information from processor E to the otherprocessors.

One of the device managers 6046 in the multiprocessor system 6008 checksthe signals from processor E checks to determine if the signals areencrypted in a recognizable protocol in block 6076. The device managerin the processor receiving the signals from processor E then checks forany data codes from the new device signals in block 6076. The data codesidentify data types used in one or more applications by processor E. Adevice ID for processor E is then determined from the output signals inblock 6080.

If all these data parameters are verified, the device managers 6046 inone or more of the processors A, B, C and D add the new processor E totheir processor arrays in block 6082. For example, processor A addsprocessor E to the processor array in memory 6065. After beingincorporated into the multiprocessor system 6008, the processor E or theapplications running on the processor E may be displayed on a graphicaluser interface in block 6084.

FIG. 7 describes in further detail the operation of the reconfigurationmanager 6044 previously described in FIG. 2. In the car multiprocessorsystem 8 there are four processors A, B, C and D. Of course there may bemore than four processors running at the same time in the car but onlyfour are shown in FIG. 7 for illustrative purposes. The processor Acurrently is operating a navigation application 60110 that uses a GlobalPositioning System (GPS) to identify car location. Processor B currentlyruns an audio application 60112 that controls a car radio and CD player.The processor C runs a car Automatic Braking System (ABS) application60114 and the processor D runs a display application 60116 that outputsinformation to the car operator through a GUI 60118.

The processor D displays an icon 60120 on GUI 60118 that represents thenavigation system 60110 running in processor A. An icon 60124 representsthe audio application running in processor B and an icon 60122represents the ABS application 60114 running in processor C.

The memory 60128 stores copies of the navigation application 60110,audio application 60112, ABS application 60114 and display application60116. The memory 60128 can also store data associated with thedifferent applications. For example, navigation data 60130 and audiodata 60132 are also stored in memory 60128. The navigation data 60130may consist of the last several minutes of tracking data obtained by thenavigation application 60110. The audio data 60132 may include thelatest audio tracks played by the audio application 60112.

The memory 60128 can be any CD, hard disk, Read Only Memory (ROM),Dynamic Random Access (RAM) memory, etc. or any combination of differentmemory devices. The memory 60128 can include a central memory that allor some of the processors can access and may also include differentlocal memories that are accessed locally by specific processors.

FIG. 8 shows one example of how the configuration manager 6044reconfigures the multiprocessor system when a failure occurs in acritical application, such as a failure of the ABS application 60114.The configuration manager 6044 for one of the processors in themultiprocessor system 6008 detects a critical application failure inblock 60134.

One or more of the configuration managers 6044 include a watchdogfunction that both monitors its own applications and the applicationsrunning on other processors. If an internal application fails, theconfiguration manager may store critical data for the failedapplication. The data for each application if stored in the memory 60128can selectively be encrypted so that only the car operator has theauthority to download certain types of data. The configuration managerdetecting the failure initiates a reboot operation for that particularapplication. The application is downloaded again from memory 60128 and,if applicable, any stored application data. If the application continuesto lockup, the configuration manager may then initiate a reconfigurationsequence that moves the application to another processor.

Failures are identified by the watchdog functions in one example byperiodically sending out heartbeat signals to the other processors. Ifthe heartbeat from one of the processors is not detected for one of theprocessors, the configuration manager 6044 for the processor thatmonitors that heartbeat attempts to communicate with the processor orapplication. If the application or processor with no heartbeat does notrespond, the reconfiguration process is initiated.

In another example, certain processors may monitor differentapplications. For example, a sensor processor may constantly monitor thecar speed when the car operator presses the brake pedal. If the carspeed does not slow down when the brake is applied, the sensor processormay check for a failure in either the braking application or the speedsensing application. If a failure is detected, the configuration managerinitiates the reconfiguration routine.

When reconfiguration is required, one of the reconfiguration managers6044 first tries to identify a processor that has extra processingcapacity to run the failed application in block 60136. For example,there may be a backup processor in the multiprocessor system where theABS application 60114 can be downloaded. If extra processing resourcesare available, the ABS application 60114 is downloaded from the memory60128 (FIG. 7) to the backup processor in block 60142.

There may also be data associated with the failed application that isstored in memory 60128. For example, the brake commands for the ABSapplication 60114 may have been previously identified for logging inmemory 60128 using a logging label described in co-pending applicationentitled: OPEN COMMUNICATION SYSTEM FOR REAL-TIME MULTIPROCESSORAPPLICATIONS, Ser. No. 09/841,753 filed Apr. 24, 2001 which is hereinincorporated by reference. The logged brake commands are downloaded tothe backup processor in block 60142.

If no backup processing resources can be identified in block 60136, theconfiguration manager 6044 identifies one of the processors in themultiprocessor system that is running a non-critical application. Forexample, the configuration manager 6044 may identify the navigationapplication 60110 in processor A as a non-critical application. Theconfiguration manager 6044 in block 60140 automatically replaces thenon-critical navigation application 60110 in processor A with thecritical ABS application 60114 in memory 60128. The processor A thenstarts running the ABS application 60114.

FIGS. 9 and 10 show an example of how the configuration manager 6044allows the user to control reconfiguration for non-criticalapplications. The applications currently running in the multiprocessorsystem 6008 are displayed in the GUI 60118 in block 60150. A failure isdetected for the navigation application 60110 running in processor A inblock 60152. The configuration manager 6044 in processor A, or in one ofthe other processors B, C, or D detects the navigation failure.Alternatively, a fusion processor 60111 is coupled to some or all of theprocessors A, B, C and D and detects the navigation failure.

In block 60154 the configuration manager 6044 for one of the processorsdetermines if there is extra capacity in one of the other processors forrunning the failed navigation application 60110. If there is anotherprocessor with extra processing capacity, the navigation application isdownloaded from memory 60128 to that processor with extra capacity alongwith any necessary navigation data in block 60156. This reconfigurationmay be done automatically without any interaction with the car operator.

If there is no extra processing capacity for running the navigationapplication 60110, the configuration manager 6044 displays the failedprocessor or application to the user in block 60158. For example, theGUI 60118 in FIG. 9 starts blinking the navigation icon 60120 inpossibly a different color than the audio application icon 60124. Atextual failure message 60125 can also be displayed on GUI 60118.

The configuration manager in block 60160 waits for the car operator torequest reconfiguration of the failed navigation application to anotherprocessor. If there is no user request, the configuration managersreturn to monitoring for other failures. If the user requestsreconfiguration, the configuration manager 6044 in block 60164 displaysother non-critical applications to the user. For example, the GUI 60118only displays the audio application icon 60124 in processor B and notthe ABS application icon 60122 (FIG. 7). This is because the audioapplication is a non-critical application and the ABS application 60114is a critical application that cannot be cancelled.

If the car operator selects the audio icon 60124 in block 60166, theconfiguration manager in block 60168 cancels the audio application 60112in processor B and downloads the navigation application 60110 frommemory 60128 into processor B. A logging manager in processor A may havelabeled certain navigation data for logging. That navigation data 60130may include the last few minutes of position data for the car while thenavigation application 60110 was running in processor A. The loggednavigation data 60130 is downloaded from memory 60128 along with thenavigation application 60110 into processor B. The navigation icon 60120in GUI 60118 then shows the navigation application 60110 running onprocessor B. At the same time the audio application icon 60124 isremoved from GUI 60118.

Referring back to FIG. 2, a processor or application is accepted intothe multiprocessor system by one or more of the device managers 6046.The configuration managers 6044 in the processors reconfigure themultiprocessor system to incorporate the processor or application. Thedata manager 6042 then detects what type of data is transmitted orreceived by the new device and determines the different processors andinput/output devices in the multiprocessor system that can receive ortransmit data to the new application or processor.

FIG. 11 shows in further detail how the data manager 6042 in FIG. 2operates. In block 60170, the data manager for one of the processorsdetermines the data standard for the data that is either transmitted orreceived by a new device. For example, the new device may be a MP3player that outputs streaming audio data. In another example, the newdevice may be a DVD player that outputs streaming video data in a MPEGformat.

One or more of the data managers 6042, identifies the device by its dataand the data, if applicable, is displayed on the graphical userinterface in block 60172. The data manager then identifies any devicesin the multiprocessor system that can output or transmit data to the newdevice in block 60174. For example, a newly detected audio source may beoutput from a car speaker. The data manager monitors for any userselections in block 60176. For example, the car operator may select theoutput from a portable CD player to be output from the car speakers. Thedata manager controlling the CD player and the data manager controllingthe car speakers then direct the output from the CD player to the carspeakers in block 60178.

FIG. 12 gives one example of how the data managers 6042 in themultiprocessing system operate. A GUI 60180 displays the audio or video(A/V) sources in a car. For example, there are three devices detected inor around the car that are A/V sources. A cellular telephone detected inthe car is represented by icon 60184, a radio is represented by icon60186, and a DVD player is represented by icon 60188.

The A/V output devices in the car are shown in the lower portion of GUI60180. For example, icons 60192, 60194, 60196, 60200, and 60204 show caraudio speakers. An in-dash video display is represented by icon 60190and a portable monitor is represented by icon 60198.

Currently, a car operator may be listening to the radio 60186 overspeakers 60192, 60194, 60196, 60200 and 60204. However, a passenger maymove into the backseat of the car carrying an MP3 player. The MP3 playerruns the DC system 6010 described in FIG. 2 and sends out a signal toany other processors in the multiprocessor system 6008 in the car. Thedevice manager 6046 and configuration manager 6044 in one of theprocessors verify the data format for the MP3 player and configure theMP3 player into the multiprocessor system.

One of the data managers 6042 determines the MP3 player outputs a MP3audio stream and accordingly generates the icon 60182 on the GUI 60180.The data manager 6042 also identifies a speaker in the MP3 player as anew output source and displays the speaker as icon 60202. The caroperator sees the MP3 icon 60182 now displayed on GUI 60180. The caroperator can move the MP3 icon 60182 over any combination of the speakericons 60192, 60194, 60196, 60200 and 60204. The output from the MP3player is then connected to the selected audio outputs.

Audio data can also be moved in the opposite direction. The speaker icon60202 represents the output of the portable MP3 player that thepassenger brought into the backseat of the car. The car operator alsohas the option of moving one or more of the other audio sources, such asthe cellular telephone 60184 or the radio 60186 icons over the speakericon 60202. If the car operator, for example, moves the radio icon 60186over the MP3 player speaker icon 60202 and the MP3 player can output theradio signals, the multiprocessor system redirects the radio broadcastout over the MP3 speaker.

It should be understood that the multiprocessor system described abovecould be used in applications other than cars. For example, FIG. 13shows a first GUI 60210 that shows different processors and applicationsthat are coupled together using the DC system 6010 in an automobile. AGUI 60212 shows another multiprocessor system comprising multipleprocessors in the home. For example, a washing machine is shown by icon60214. The DC system allows the washing machine processor to communicateand be configured with a television processor 60216, toaster processor60218, stereo processor 60220, and an oven processor 60222.

FIG. 14 shows a car 3312 that includes multiple processors 3314, 3316,3318 and 3320. The engine monitor processor 3314 in one configurationmonitors data from different sensors 3322 and 3324 in the car engine.The sensors 3322 and 3324 can be any sensing device such as sensors thatmonitor water temperature, oil temperature, fuel consumption, car speed,etc. The brake control processor 3320 monitors and controls an AutomaticBraking System (ABS) 3328. The display processor 3316 is used to controland monitor a graphical or mechanical user interface. The securityprocessor 3318 monitors and controls latches and sensors 3330 and 3332that are used in a car security system.

Typical networks, such as in an office network environment, enablemultiple computers to communicate with each other. Applications such asprinting jobs can be launched from any one of the networked computers.If one of the networked computers crashes or is busy, a user mustmanually send the job to another computer. The other computer thenhandles the task like any other locally received task.

In a car environment, tasks must be processed with different prioritiesin real-time. For example, the braking tasks in the brake processor 3320have to be processed with a high priority while a radio selection taskperformed in the display processor 16 can be processed with a relativelylow priority. The processors 3314, 3316, 3318 and 3320 all includesoftware that runs an Open Communication (OC) system 3310 that enablesthe multiple processors to transfer data and exchange messages forperforming these real-time car applications.

If the processor 3320 currently running the high priority brakingapplication fails, the OC system 3310 allows the braking tasks to beoffloaded to another processor in car 3312, such as the displayprocessor 3316. The OC system 3310 automatically assigns a high priorityto the braking tasks that allow the braking tasks to override lowerpriority tasks, such as the radio application, that are currently beingperformed in display processor 3316.

The OC system 3310 also ensures that data in each processor is processedin a secure manner for the car environment. The security portion of theOC system 3310 prevents unauthorized devices from accessing thedifferent car applications. The OC system 3310 also includes a loggingportion that allows data in the car system to be automatically logged.This is important for accident reconstruction purposes. The OC system3310 also allows different processors to communicate over differentcommunication protocols and hardware interfaces. Any processor thatincludes an OC system 3310 can be integrated in the system shown in FIG.14. This allows different processors and different applications can beseamlessly replaced and added to the overall multiprocessor system.

The description below gives only a few examples of the differentprocessors and different applications that can implemented using the OCsystem 3310. However, any single or multiprocessor system located eitherinside or outside of car 3312 can communicate and exchange data usingthe OC system 3310. It should also be understood that the OC system 3310can be used in any real-time network environment such as betweenprocessors used in appliances and computers in the home.

FIG. 15 is a block diagram of the communication managers used in the OCsystem 3310 described in FIG. 14. The different communication managersin the OC system 3310 are configured to provide the necessary controlfor operating a distributed processor system in a real-time carenvironment. Applications 3348 are any of the different applicationsthat can be performed for the car 3312 shown in FIG. 14. For example,applications can include car displays, braking control, securitysystems, sensor monitoring, airbag deployment, etc. One or moreapplications can be run in the same processor at the same or atdifferent times.

A car interface manager 46 operates as an Application ProgrammersInterface (API) that can be implemented in any variety of differentlanguages such as Java, C++, Extensible Markup Language (XML) orHyperText Markup Language (HTML), etc. The car interface manager 3346enables applications 3348 to be written in any variety of differentlanguages. This prevents the applications 3348 from having to be writtenspecifically for the car environment or for a specific communicationprotocol. Thus, applications written for other systems can be reused inthe car system described below. The car interface manager 3346 readsbasic processing and data transfer commands needed to transfer data andmessages between different processors and storage mediums inside oroutside the car 3312.

For clarity the terms ‘message’ and ‘data’ are used interchangeablybelow. After a message passes through the car interface manager 3346, apriority manager 3344 determines a priority value for the message thatdetermines how the message is processed both in the local processor 3350and in other processors such as processor 3352. Referring to FIG. 16, anoutgoing message is identified by the priority manager 3344 in block3360. A priority for the message is identified in block 3362 by readinga priority value that the generic car interface manager 3346 hasattached to the message.

In block 3364, the priority manager 3344 compares the priority value forthe outgoing message with the priority values for other messages in theprocessor. The priority manager 3344 ranks the outgoing message withrespect to the other messages and then sends the message to the loggingmanager 3342 in block 3366 (FIG. 15). For example, there may be severalmessages that either need to be output or received by a particularprocessor. An output message with a high priority value, such as a crashindication message, will be assigned higher priority than other messagesand will therefore be immediately transmitted by the processor 3350before other lower priority messages.

FIG. 17 shows how the priority manager 3344 receives messages from otherprocessors. There may be multiple applications running on the sameprocessor and multiple messages and data sent from other processors tothose applications. For example, multiple sensors may be sendingdifferent types of data to a video display application running on one ofthe processor 3350 (FIG. 15). That same processor 3350 may also bereceiving different types of sensor data for running an airbagdeployment application. The priority manager 3344 determines the orderthat messages are processed by the different applications that reside onprocessor 3350.

In block 3368, the priority manager 3344 reads the priority labels forincoming messages. If the priority of the message is not high enough torun on the processor in block 3370, the data or message is rejected inblock 3376. The priority manager 3344 may send out a message to thesending processor indicating the message has been rejected. In somesituations, the message or data may have such a low priority that anacknowledge message does not have to be sent back to the sendingprocessor. For example, inside temperature data from a temperaturesensor may be sent to one or more processors with no requirement thatthe processor accept or acknowledge the data. In this case thetemperature data is sent with a very low priority value that indicatesto the priority manager 3344 that no message needs to be sent back tothe temperature sensor even if the data is rejected.

The priority manager 3344 in block 3372 ranks the priority of theincoming message in relation to the priorities of all the other messagesin the processor. The priority manager in block 3374 decides accordingto the ranking whether the message should be put in a queue or sentdirectly to the application for immediate processing. For example, acrash indication message may have a high enough priority to cause thepriority manager 3344 to delay all data currently being processed by allother applications in the same processor. The priority manager 3344directs all the applications to wait while the current high prioritycrash indication message is processed. The other data and messages arequeued in the processor and processed after the crash indication messagehas been completed.

Referring to FIGS. 15 and 18, a logging manager 3342 controls what datais logged by different processors. It may be important to log criticalfailures that occur during an accident. For example, it may be importantto verify that a particular processor sent an air bag deployment messageand that another processor successfully received the airbag deploymentmessage. This would allow insurance companies and other entities toreconstruct accidents by identifying when and where different messageswere sent and received.

The logging manager 3342 receives either an incoming message over acommunications link for sending to a local application 3348 or receivesan outgoing message from one of the local applications 3348 for sendingout over the communications link to another processor in block 3380. Thelogging manager 3342 reads a logging label in the message in block 3382.If the logging label indicates that no logging is required, the messageis sent on to the next communication manager in block 3388. If it is anoutgoing message it is sent to the security manager 3340 (FIG. 15). Ifit is a incoming message it is sent to the priority manager 3344. If themessage requires logging, the logging manager 3342 stores the message ina memory in block 3386. The logging label may indicate a particular typeof memory for logging, such as a nonvolatile Flash memory or, ifavailable, a high volume hard disk peripheral memory.

The logging manager 3342 in each processor, provides the OC system 3310with the unique ability to track when and where messages are sent andreceived at different processors in the multiprocessor car system. Thisis important in accident reconstruction allowing the logging managers3342 to identify which processors and applications failed and also thesequence in which the different processors and associated applicationsfailed.

The logging manager 3342 can also track unauthorized messages and datathat may have caused any of the processors in the car to crash. Forexample, an audio processor that handles audio applications in the carmay crash due to unauthorized downloading of MP3 music from a laptopcomputer. The logging manager 3342 can log the unauthorized datareceived from the laptop MP3 player. The logging manager 3342 logs anydata that does not have a particular security or priority label value. Asystem administrator can then down load the MP3 data to identify whatcaused the audio processor to crash.

Referring to FIGS. 15 and 19, a security manager 3340 provides securityfor applications both receiving and transmitting messages. For instance,a laptop computer may be connected to a Ethernet port in the car 3312(FIG. 14). If the laptop computer does not use the OC system 3310, datafrom that laptop application is not allowed to access certain processorsor certain applications in the car 3312. For example, audio data shouldnot be sent or processed by a processor that performs car brakingcontrol.

The security manager 3340 in block 3390 reads a message either receivedfrom an application on the same processor or received over acommunication link from another processor. The security manager 3340determines if there is a security value associated with the message inblock 3392. If there is no security value associated with the data, thesecurity manager 3340 may drop the data in block 33100. However, someapplications, such as a processor that plays audio data may not requirea security label. In this case, the security manager in block 3394allows the data to be passed on to the application in block 3398.

In other instances the data or message may have a security value, butthat security value is not sufficient to allow processing on the presentapplications. For example, data for car security monitoring may be sentto a processor that controls air bag deployment and an automatic brakingsystem. The two currently running applications may set a minimumsecurity level for receiving data. If data received from otherprocessors do not have that minimum security level in block 3396, thedata is dropped in block 33100. Otherwise, the data or message is passedon to the next communication layer for further processing in block 3398.Thus the security manager 3340 prevents unauthorized data or messagesfrom effecting critical car applications.

Referring back to FIG. 15, an operating system layer 3338 identifies thecommunication platform used for communicating the data or message over alink identified in a hardware/link interface 3336. The operating system3338 then formats the message for the particular communication stack andmedium used by the identified link 3354. For example, the operatingsystem layer 3338 may identify a first message being transmitted over aBluetooth wireless link and a second message transmitted over aTransmission Control Protocol/Internet Protocol (TCP/IP) packet switchedlink. The data or message adds whatever headers and formatting isnecessary for transmitting the first message over the Bluetooth wirelesslink and the second message over the TCP/IP hardwired link.

The hardware/link interface 3336 includes the software and hardwarenecessary for interfacing with different communication links 3354. Forexample, the two processors 3350 and 3352 may communicate over aEthernet link, 802.11 wireless link, or hardwired Universal Serial Buslink, etc. The software necessary for the two processors to communicateover these different interfaces is known to those skilled in the art andis therefore not described in further detail.

FIG. 20 describes one example of an application that uses the OC system3310 described above in FIGS. 14-19. A car 33102 includes an radarsensor 33104 that is controlled by a radar processor 33106. The radarsensor 33104 is located in the front grill of car 33102. An InfraRed(IR) sensor 33110 is controlled by an IR processor 33112 and is locatedon the front dash of car 33102. A braking system 33123 is controlled bya brake control processor 33122. The IR processor 33112 is connected toa fusion processor 33114 by an Ethernet link 33116 and the radarprocessor 33106 is connected to the fusion processor 33114 by a 802.11wireless link 33108. The brake processor 33122 is connected to thefusion processor 33114 by a CAN serial link 33120. The fusion processor33114 is also coupled to a display screen 33118.

The radar sensor 33104 in combination with the radar processor 33106generates Radar Track Reports (RTRs) 33130 that are sent to the fusionprocessor 33114. The IR sensor 33110 in combination with the IRprocessor 33112 generate Infrared Track Reports (ITRs) 33128 that aresent to the fusion processor 33114.

Referring to FIG. 21, each track report 33128 and 33130 includescommunication link headers 33132 for communicating over an associatedinterface medium. In this example, the radar track report 33130 includesthe link headers 33132 necessary for transmitting data over the 802.11link 33108. The infrared track report 33128 includes the link headers33132 for transmitting data over the Ethernet link 33116.

The track reports 33128 and 33130 include Open Communication (OC) labels33133 for performing the OC operations described above. A security label33134 is used by the security manager for preventing unauthorized datafrom being downloaded into one of the car processors and disruptingapplications. A logging label 33136 is used by the logging manager toidentify data that needs to be logged in a local memory. The prioritylabel 33138 is used by the priority manager for scheduling messages ordata to the applications run by the processors. The link headers 33132,security label 33134, logging label 33136 and priority label 33138 areall part of the data 33131 used by the open operating system 33131.

The radar processor 33106 and IR processor 33112 also send a time ofmeasurement 33140 and other data 33142 from the radar sensor 33104 andIR sensor 33110, respectively. The data 33142 can include kinematicstates of objects detected by the sensors. The time of measurement data33140 and other sensor data 33142 is referred to as application data33139 and is the actual data that is used by the application.

FIGS. 22 and 23 show one example of how the radar and infrared sensordata is processed by the OC system 3310. One or both of the radarprocessor 33106 and the IR processor 33112 may generate image data 33150and 33152 for the area in front of the car 33102 (FIG. 20). Forsimplicity, the discussion below only refers to an image generated byradar sensor 33104. At a first time t=t.sub.1, sensor 33104 detects asmall far away object 33154. At another time t=t.sub.2, sensor 33104detects a large up-close object 33156.

The applications described below are all performed by the OC system 3310thus preventing the applications from having to handle the tasks. Thisallows the applications to be written in a completely portable fashionwith no knowledge of the network hardware, security, priority andlogging operations. This greatly reduces the cost of creatingapplications.

An image processing application in the processor 33106 identifies theobject 33154 as a small far away object in block 33158. The image andkinematic data for the object is output by the OC system 3310 as a radartrack report 33130. The security manager 3340 (FIG. 15) in the radarprocessor 33106 adds a security label 33134 to the report in block 33160and the logging manager 3342 may or may not add a logging label to thereport in block 33162. In this example, the object 33154 has beenidentified by the image processing application as a small far awayobject. Therefore, the logging manager does not label the track reportfor logging. The priority manager 3344 (FIG. 15) adds a priority label33138 (FIG. 21) to the report in block 33164. Because the imageprocessing application identifies the object 33154 as no critical threat(small far away object), the priority label 33138 is assigned a lowpriority value in block 33164.

The OC system 3310 then formats the radar track report in block 33168according to the particular link used to send the report 33130 to thefusion processor 33114. For example, the operating system 3338 and thehardware/link interface 3336 (FIG. 15) in the radar processor 33106attaches link headers 33132 to the track report 33130 (FIG. 21) fortransmitting the report 33130 over the 802.11 link. The track report33130 is then sent out over the link 33108 in block 33168 to the fusionprocessor 33114.

Referring next to FIGS. 20-23, the fusion processor 33114 includes awireless interface 33119 that communicates with the wireless 802.11 link33108 and an Ethernet interface 33117 that communicates with theEthernet link 33116. The hardware/link interface 3336 in the fusionprocessor OC system 3310 uses the link headers 33132 (FIG. 21) toreceive the radar track report 33130 in block 33182 and process thereports in block 33184 (FIG. 23).

The OC system 3310 reads the security label in block 33186 to determineif the track report has authority to be processed by the fusionprocessor 33114. If the track report passes the security check performedby the security manager in block 33186, the logging manager in block33188 checks to see if either the received radar data needs to belogged. In this example, the image processing application in the radarprocessor identified the object 33154 (FIG. 22) to be within aparticular size range and distance range that does not indicate acritical crash situation. Therefore, the track report 33130 was notlabeled for logging. The fusion processor 33114 therefore does not logthe received report in block 33188.

Because the image 33150 was identified as non-critical, the prioritylabel 33138 (FIG. 21) for the track report 33130 is given a low priorityvalue. The fusion processor 33114 ranks the track report with the otherdata that is being processed and then processes the report according tothe ranking.

Different applications in the fusion processor 33114 may or may not beperformed depending on the track report. For example, the object 33154may be sent to a video display in block 33194. However, the fusionprocessor 33114 will not send a brake command in block 33196 to the carbraking system 33123. This is because the image has been identified asnon-critical. Similarly, no audio warning is sent to the car audiosystem in block 33198 because the object has been identified asnon-critical.

Referring back to FIG. 22, in another example, the IR processor 33112,the radar processor 33106, or both, in block 33170 detect at timet.sub.2 an object 33156 that is large and close to the car 33102. Forsimplicity, it is assumed that only the IR processor 33112 hasidentified object 33156. The IR processor 33112 generates a track report33128 in block 33170 and the OC system in the IR processor 33112 adds asecurity label 33134 (FIG. 21) to the report in block 33172. Because theobject 33156 has been identified as being within a predetermined sizeand within a predetermined range of car 33102 (critical data), thelogging manager in the IR processor 33112 assigns a logging label value33136 to the IRT 33128 that directs all processors to log the image data33142. The image data is logged by the IR processor 33112 in a localmemory in block 33174.

Because the IR track report 33128 has been identified as critical data,the priority manager 3344 in the IR processor 33112 assigns a highpriority label value 33138. This high priority value is read by theoperating system 3338 and interface hardware 3336 (FIG. 15) in blocks33178 and 33180. Accordingly the IR track report 33128 is givenpreference when being formatted in block 33178 and transmitted in block33180 over Ethernet link 33116 to the fusion processor 33114.

Referring again to FIG. 23, the IR track report 33128 is received by thefusion processor 33114 in block 33182 and the link processing performedin block 33184. This link processing is known to those skilled in theart and is therefore not described in further detail The report may begiven higher link processing priority in the fusion processor 33114based on a priority value assigned in the link headers 33132.

The security manager 3340 in the fusion processor 33114 confirms thereis an acceptable value in the security label in block 33186 and thenpasses the IR track report 33128 to the logging manager in block 33188.The logging manager 3342 in the fusion processor 33114 reads the logginglabel and accordingly logs the image data in a local nonvolatile memory.This provides a history of the image 33156 that was detected by the IRsensor 33110.

The logged image data may then be used in subsequent accident analysis.For example, an accident reconstruction specialist can download thelogged image data or message in both the IR processor 33112 and in thefusion processor 33114 to determine when the image data 33140 and 33142was first detected. It can then be determined whether the image data wassent by the IR processor 33112 and received by the fusion processor33114.

The priority manager reads the priority label 33138 in block 33190 anddetermines that the IR track report has a high priority. Accordingly,the track report is immediately sent to different applications in block33192. The priority manager 3344 may first send the track report to thebrake control application in block 33196. The brake control applicationimmediately sends a brake command 33125 (FIG. 20) to the brake processor33122.

The logging manager 3342 in the fusion processor 33114 adds a logginglabel 33136 to the outgoing brake command 33125. Both the fusionprocessor 33114 and the brake control processor 33122 will then both logthe brake command 33125. Thus, not only is the sequence of transmissionsof the image data and messages logged in both the IR processor 33112 andfusion processor 33114 but also the sequence of the brake message 33125from the fusion processor 33114 to the brake processor 33122. Thisfurther adds to any accident analysis data that may need to be obtainedfrom the car if an accident occurs.

The IR data may also be sent to an audio application in block 33198 thatimmediately sends out an audio alarm over the car stereo system or outover a car horn. This automatically warns both the car driver and theobject 33156 in front of car 33102 of a possible collision. In a thirdapplication, the fusion processor 33114 may send the IR image data to animage display 33118 in block 33194.

FIG. 24 is a block diagram showing another example of how the OC 3310exchanges information according to the type of data independently of thephysical links that connect the different applications together. Aprocessor A runs an application 33202. In this example, the application33202 is an IR processing application that receives IR data from an IRsensor 33200 and outputs the IR data as a sensor report. A processor Bruns a fusion processing application 33220 that controls other carfunctions in part based on the IR sensor report.

The OC system 33208 includes a control table 33212 that includes severalparameters associated with a SENSOR REPORT 33210. For example, theSENSOR REPORT 33210 may need to include a priority label, a securitylabel or a logging label. The security label also includes one or morelocations where the SENSOR REPORT 33210 should be sent. The IRapplication 33202 includes a CONNECT TO SEND (SENSOR REPORT) commandthat the OC 3310 then uses to establish a slot in memory for the SENSORREPORT. When IR data is received from the IR sensor 33200, the IRapplication 33202 generates sensor data (FIG. 21) for the SENSOR REPORT33210 and stores that sensor data in the memory slot established by theOC system 3310. The sensor data is contained within the application datasection 33139 of the sensor report shown in FIG. 21. The IR application33202 then issues the SEND(SENSOR REPORT) command 33206 to notify the OC3310 that there is a SENSOR REPORT in the reserved slot in memory.

The OC system 3310 attaches a security label 33134, logging label 33136and priority label 33138 to the SENSOR REPORT 33210 as describedpreviously in FIG. 21. The OC system 3310 then adds the necessary linkheaders 33132 (FIG. 21) that are required to send the SENSOR REPORT33210 to other identified applications. The control table 33212 includessecurity parameters associated with the SENSOR REPORT data type. One ofthe SENSOR REPORT security parameters, in addition to a security value,is an identifier 33213 for the fusion application 33220 running inprocessor B. The identifier 33213 identifies whatever address, format,and other protocol information is necessary for transmitting the SENSORREPORT 33210 to the fusion application 33220. The OC system 3310attaches the link headers 33132 to the SENSOR REPORT 33210 and thensends the report through a hardware interface 33209 over a link 33211 toprocessor B.

The fusion application 33220 works in a similar manner and initiates aCONNECT TO RECEIVE (SENSOR REPORT) command to the OC system 3310 runningin the same processor B. The OC system 3310 reserves a slot in localmemory for any received SENSOR REPORTs 33210. The fusion application33220 issues a WAIT ON (SENSOR REPORT) command that continuously waitsfor any SENSOR REPORTs 33210 sent by the IR application 33202. The OCsystem 3310 control table 33214 also identifies from the SENSOR REPORTdata type the communication link 33211, hardware interface 33215 andother associated communication protocols used for receiving the SENSORREPORT 33210.

Whenever a SENSOR REPORT 33210 is received, the OC system 3310 inprocessor B performs the security, logging and priority managementoperations described above based on the labels 33134, 33136 and 33138 inthe sensor report 33210 (FIG. 21). The OC system 3310 then places thesensor data from the SENSOR REPORT 33210 in the memory slot reserved inlocal memory. The OC system 3310 detects the data in the reserved memoryslot and processes the sensor data. Another portion of the fusionapplication 33220 may send out a BRAKE command based on the sensor data.The control table 33214 for the OC system 3310 in processor B alsoincludes the necessary system parameters for sending a BRAKE REPORT toanother processor in the multiprocessor system, such as a brakeprocessor.

The communication link between the fusion application 33220 and thebrake application may be completely different than the link between theIR application 33202 and the fusion application 33220. However, thefusion application 33220 outputs the SENSOR REPORT and the BRAKE REPORTin the same manner. The OC system 3310 then uses stored link informationin the control table 33214 to communicate to the IR application 33202and the brake application over different links.

Thus, the IR application 33202 and the fusion application 33220 do notneed to know anything about the physical links, address, or any of theother operations that are used to transmit data over differentcommunication links.

The system described above can use dedicated processor systems, microcontrollers, programmable logic devices, or microprocessors that performsome or all of the communication operations. Some of the operationsdescribed above may be implemented in software and other operations maybe implemented in hardware.

For the sake of convenience, the operations are described as variousinterconnected functional blocks or distinct software modules. This isnot necessary, however, and there may be cases where these functionalblocks or modules are equivalently aggregated into a single logicdevice, program or operation with unclear boundaries. In any event, thefunctional blocks and software modules or described features can beimplemented by themselves, or in combination with other operations ineither hardware or software.

Having described and illustrated the principles of the invention in apreferred embodiment thereof, it should be apparent that the inventionmay be modified in arrangement and detail without departing from suchprinciples. Claim is made to all modifications and variation comingwithin the spirit and scope of the following claims.

The system described above can use dedicated processor systems, microcontrollers, programmable logic devices, or microprocessors that performsome or all of the communication operations. Some of the operationsdescribed above may be implemented in software and other operations maybe implemented in hardware.

For the sake of convenience, the operations are described as variousinterconnected functional blocks or distinct software modules. This isnot necessary, however, and there may be cases where these functionalblocks or modules are equivalently aggregated into a single logicdevice, program or operation with unclear boundaries. In any event, thefunctional blocks and software modules or described features can beimplemented by themselves, or in combination with other operations ineither hardware or software.

Having described and illustrated the principles of the invention in apreferred embodiment thereof, it should be apparent that the inventionmay be modified in arrangement and detail without departing from suchprinciples. Claim is made to all modifications and variation comingwithin the spirit and scope of the following claims.

What we claim:
 1. A system used in a vehicle, comprising: multipleprocessors located on-board the vehicle and adapted to run differentreal-time vehicle applications; a communication system configured tocouple the multiple processors together over multiple communicationlinks; a dynamic configuration system configured to operate on at leastsome of the multiple processors and automatically detect and connect newhardware devices to at least some of the multiple processors; aconfiguration manager configured to automatically reconfigure differentones of the multiple processors to take over running of the differentvehicle applications from other ones of the multiple processors andstart processing data obtained from the other ones of the multipleprocessors in response to the new hardware devices being detected andconnected to the multiple processors, a data manager configured toidentify data generated by the new hardware devices and load applicationdata from memory to dynamic random access memory to process the data andidentify which of the multiple processors can input or output theidentified data; a display processor configured to generate imagesrepresenting the new hardware devices detected or connected to themultiple processors; and a user input system configured to receiveinputs directing operation of the multiple processors.
 2. The system ofclaim 1 wherein the vehicle applications include one or more of thefollowing: car braking; audio control; video control; car sensormonitoring; car display control; car security monitoring; cartemperature control; car lighting control; and car airbag monitoring. 3.The system of claim 1 wherein the communication system includes supportfor an IEEE 802.11 link, a Bluetooth link, a hard-wired link, a satcomlink, and a cellular link.
 4. The system of claim 1, wherein theconfiguration manager is further configured to: monitor the vehicleapplications running on the multiple processors; identify a failure fora high priority one of the vehicle applications operating on a first oneof the multiple processors; identify a lower priority one of the vehicleapplications operating on a second one of the multiple processors; andreconfigure the multiple processors to run the high priority one of thevehicle applications on the second one of the multiple processors inresponse to identifying the failure.
 5. The system of claim 1 whereinthe configuration manager is further configured to: store a copy of ahigh priority one of the vehicle applications in the memory; identify afailure of the high priority one of the vehicle applications on a firstone of the multiple processors; identify a second one of the multipleprocessors currently running another one of the vehicle applications;download the copy of the high priority one of the vehicle applicationsfrom the memory to the second one of the multiple processors in responseto identifying the failure of the high priority one of the vehicleapplications on the first one of the multiple processors; and run thedownloaded copy of the high priority one of the vehicle applications onthe second one of the multiple processors.
 6. The system of claim 1wherein: the data manager is further configured to: identify a failedone of the vehicle applications that has failed on a first one of themultiple processors; store critical data generated by the identified oneof the vehicle applications; and configure a second one of the multipleprocessors to run the identified one of the vehicle applications; anddownload and process the critical data with the identified one of thevehicle applications running on the second one of the multipleprocessors in response to the failure of the identified one of thevehicle applications on the first one of the multiple processors.
 7. Thesystem of claim 1 further comprising a user interface configured to:identify a failure associated with an identified one of the vehicleapplications running on one of the multiple processors; identify othervehicle applications running on other ones of the multiple processorsthat can be replaced by the identified one of the vehicle applications;and display the identified other vehicle applications on a userinterface.
 8. The system of claim 1 wherein the data manager is furtherconfigured to: identify a type of data transferred by the new hardwaredevices; identify an application configured to process the type of data;and display the application on a user interface.